@ziliguo Could you leave how you verified?

@ziliguo Could you leave how you verified?

Hello @sunghan-chang

Our verification is divided into two steps:

1.Only removed the duplicate references to Make.defs under bk_cli, which solved the issue of CFLAGS being overwritten. This way, the stack overflow problem can also be reproduced with the code from GitHub.

2. Based on the above scenario where the issue can be reproduced, we moved the configuration of stack_chk_guard out of the board_init function and relocated it before os_start, and then re-verified that the above issue could not be reproduced.

This change not only ensures that the function of the stack guard is retained, but also resolves the issue of false stack overflow reports.

@ziliguo Could you leave how you verified?

Hello @sunghan-chang

Our verification is divided into two steps:

1.Only removed the duplicate references to Make.defs under bk_cli, which solved the issue of CFLAGS being overwritten. This way, the stack overflow problem can also be reproduced with the code from GitHub.

2. Based on the above scenario where the issue can be reproduced, we moved the configuration of stack_chk_guard out of the board_init function and relocated it before os_start, and then re-verified that the above issue could not be reproduced.

This change not only ensures that the function of the stack guard is retained, but also resolves the issue of false stack overflow reports.

@Poly-J Do you verify the stack guard functionality itself after enabling?

@ziliguo Could you leave how you verified?

Hello @sunghan-chang
Our verification is divided into two steps:
1.Only removed the duplicate references to Make.defs under bk_cli, which solved the issue of CFLAGS being overwritten. This way, the stack overflow problem can also be reproduced with the code from GitHub.

2. Based on the above scenario where the issue can be reproduced, we moved the configuration of stack_chk_guard out of the board_init function and relocated it before os_start, and then re-verified that the above issue could not be reproduced.

This change not only ensures that the function of the stack guard is retained, but also resolves the issue of false stack overflow reports.

@Poly-J Do you verify the stack guard functionality itself after enabling?

Hello @sunghan-chang

Yes, I have also verified this with standalone functional testing. The test scenario I used was as follows: I constructed a function with a local-variable overflow and called it during system initialization。

the code is as follows:
`attribute((noinline))

static void test_stack_guard_overflow(void)

{

char buf[16];  

lldbg("test_stack_guard_overflow\r\n");

/* Intentional overflow - will trigger __stack_chk_fail if stack guard works */

memset(buf, 0x41, 32);  /* overflow 16 bytes */

}`

The test log is shown below:

_[i2c]I2C(0) init ok, baud_rate:0

i2c_uioregister: Registering /dev/i2c-0

[hal]spi select src_clk xtal

[cal]calibration_main(unknown-48Pin) over

[cal]rf cali flag in flash: valid

[cal]tx_i_dc_2G: 0x7e9,tx_q_dc_2G: 0x80f

[cal]tx_q_dc_5G: 0x819,tx_q_dc_5G: 0x812

[cal]invalid 2test_stack_guard_overflow: test_stack_guard_overflow

Stack guard warning, local buffer overflow!!!

===========================================================

Assertion details

===========================================================

print_assert_detail: Assertion failed at file:components/bk_init/components_init.c line: 320 task: AppBringUp_

At the same time, for the modified firmware, in addition to testing the stack guard functionality itself, we also tested other features such as Bluetooth and Wi‑Fi, and did not find any issues.